Manufacturers of high volume products have several options for programming programmable devices in a product. One option is to program the devices prior to assembling and soldering the devices to a printed circuit board (PCB). Another option is to program the devices after they are soldered to the PCB.
On board programming is generally more flexible due to the nature of programming the parts later in the manufacturing process. Less potential rework exists when the customization of the product occurs later in the process. Sending out programmable devices for programming can cause a two to ten day delay. This delay creates a need for up to ten days of pre-programmed devices on-hand. When a programming change occurs, all of the pre-programmed devices on-hand and in the pipeline require re-programming. Programming the devices on board reduces this two to ten day supply down to zero, reducing the need for re-programming to just the PCBs that are already produced, which would be required in either scenario.
There are several options for programming devices on board. A common method is to utilize an In-Circuit Tester (ICT) to download the code to the device. In a high volume-manufacturing environment, the time of download plus the actual ICT test time must be within the time requirements of the manufacturing process or a bottleneck in the process may form at ICT. Improvements to the flash programming speed may eliminate this bottleneck. Programming done within the required timeframe at the ICT is nearly free, while programming out of house or on separate platforms can be expensive. If the programming is done using the ICT, when in-circuit testing is already performed, the cost may be close to zero. The speed of programming is critical to obtaining this near zero cost.
ICTs typically use a vector processor for testing and programming. Essentially, the vector-based systems are good at “fixed” programming algorithms, but are unable to handle programming methods in which decisions are made on the fly. Unfortunately, these vector-based systems cannot program NAND flash devices or NOR/NAND combined flash devices. A NOR/NAND combined flash device includes both NOR features and NAND features. The combined flash technology goes by several commercial names, such as Spansion's ORNAND and Samsung's ONENAND.
Industry is increasingly using NAND flash devices due to its low cost, small package size, and larger capacity. Each NAND flash device is considered unique as each device typically has a unique set of bad cells. Thus, programmed NAND flash devices are not direct copies as data is stored in different “good” areas of the devices. A vector-based system cannot make the decisions necessary to adjust for the bad cell problem in NAND flash devices. As a result, NAND flash cannot be programmed by the ICT. The same holds true of the NOR/NAND combined technology due to its NAND features.
Therefore, a method for programming NAND flash devices and NOR/NAND combined flash devices during in-circuit testing would be beneficial.